-
Notifications
You must be signed in to change notification settings - Fork 214
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore(pp-upgrade): test functionality after provisionPool and bank upgrade #10419
Conversation
Deploying agoric-sdk with Cloudflare Pages
|
e375cde
to
51a631d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suspect that it would be a good idea to convert makeBridgeProvisionTool
from a Far object to an Exo, but I'm not positive. I've asked for advice and will let you know what I hear.
The response I got was "yes, convert it to an Exo", but it appears that this object may be one of those discussed in #8849, which may mean we need a clearer story on upgrading the bootstrap vat (V1) before we can proceed to upgrade provisionPool. You can work on converting it to an Exo I need to have more design discussions with the kernel team about the impact. The concern seems to be about whether auto-provisioning will continue to work. The links mentioned were
|
#10425 tracks this now. From your comment I understand the path for this PR to land;
Could you please confirm? @Chris-Hibbert |
Let's pursue 10425. If we can write tests that show the bootstrap vat doesn't break, and we can continue to provision new wallets, I don't think we have to be able to upgrade vat-bootstrap before upgrading provisionPool. |
51a631d
to
6fdcf87
Compare
1e8f8d0
to
bc5a94e
Compare
bc5a94e
to
a8b124a
Compare
a3p-integration/proposals/p:upgrade-19/nullUpgradePP/null-upgrade-pp-permit.json
Outdated
Show resolved
Hide resolved
a3p-integration/proposals/p:upgrade-19/depositUSD-LEMONS/deposit-usd-lemons.js
Outdated
Show resolved
Hide resolved
d5f827a
to
58e7583
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I requested a few clean-ups, but this looks good. Thanks.
* @param {string} wanted | ||
* @param {string} [from] | ||
*/ | ||
export const bankSend = (addr, wanted, from = VALIDATORADDR) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please pull bankSend
, provision
, introduceAndProvision
, getProvisionedAddress
, and checkUserProvisioned
out to a separate library file that can be shared. We shouldn't have to define these more than once.
Maybe getProvisionedAddress
is simple enough that it doesn't have to go in the library.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please pull
bankSend
,provision
,introduceAndProvision
,getProvisionedAddress
, andcheckUserProvisioned
out to a separate library file that can be shared. We shouldn't have to define these more than once.
#10514 already tracks this one. I can put those methods into a helper module then move them to the shared library as part of #10514. I think we shouldn't wait for the shared library to land this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we shouldn't wait for the shared library to land this PR
That's fine.
6e7cda9
to
9c75709
Compare
6ae5628
to
7346df1
Compare
We talked about commenting about
I think the issue is related to this PR that recently landed #10418 @Chris-Hibbert |
I ran into a similar issue. My conclusion was that the upgrades that are not in U18 should be cleanly moved to u19 and tested there. If that means you have to move some tests from U18 or correct some expected output in U18 in |
7346df1
to
ce1e94f
Compare
Yep, I think it's resolved in master. I rebased my branch on top of the master. Could you please approve the PR if it looks good to you? @Chris-Hibbert |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -1,5 +1,8 @@ | |||
import { E } from '@endo/far'; | |||
import { deeplyFulfilled } from '@endo/marshal'; | |||
import { makeTracer } from '@agoric/internal'; | |||
|
|||
const tracer = makeTracer('UpgradeProvisionPool'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
not a big deal,but we usually call this trace
.
…grade Refs: #10395 fix: format fixes
Make sure the handler returned from E(creatorFacet).makeHandler() is durable and provisionPool is upgradable multiple times. Refs: #10425 Refs: #10564 fix: remove unnecessary comment chore: get rid of ephemera, address change requests Refs: #10395 Refs: #10425 fix: drop trace chore: address change requests fix: rebase fixes fix: yarn.lock fix fix: bring back missing upgrade-paRegistry proposal
ce1e94f
to
164151e
Compare
closes: #10395
closes: #10425
closes: #10564
Description
As mentioned in #8158, we need the ability to restart or replace all vats. This PR focuses on the vats v28-provisionPool and v14-bank. The goal is to make sure after upgrading both of those vats, v28-provisionPool functionality keeps working. We pay special attention to #8722 and #8724 during the tests as those issues were identified as potential problems against v28-provisionPool upgrade.
Security Considerations
v28-provisionPool and v14-bank are critical vats for the system when it comes to onboarding new users and keeping track of ERTP representations of user assets. Reviewers, please highlight the slightest risk you see.
Scaling Considerations
v28-provisionPool vat has a linear relationship with the number of users entering the Agoric system. So it is pretty important it keeps working. Reviewers, please highlight the slightest risk you see.
Documentation Considerations
None.
Testing Considerations
During the testing, we focused on
provisionPoolAddress
' cosmos level balances as our source of truth. The reasoning behind this is; if the IST balance of theprovisionPoolAddress
it can only meanIn our test we send two anchor assets;
Upgrade Considerations
Both v28-provisionPool and v14-bank are staged upgrades in
upgrade.go